fix(ci): Star Check resilient to read-replica lag (fixes #55 false positive)#56
Merged
Merged
Conversation
The Star Check workflow's first attempt used a non-existent Octokit method (`checkRepoIsStarredByAuthenticatedUserAtUsername`) and immediately fell through to a single raw API request. On fresh stars from first-time fork contributors, GitHub's read-replica serving the cross-user star-check endpoint often lags 5-30s behind the primary write — so the single-shot check returned 404 and the contributor (who had correctly starred) was blocked from merging. Symptom: #55 Fix: - Drop the bogus Octokit method, use the raw GET /users/{username}/starred/{owner}/{repo} path directly. - Add a 3-attempt loop with 3s/6s/12s exponential backoff. - 401/403 fail fast (no point retrying an auth/perm error). - Diagnostic metadata (lastStatus, lastErr) appended to the failure log so the maintainer can distinguish read-replica lag from real misses. - Slightly clearer 'false positive' guidance in the contributor-facing failure message. Net worst-case step time: ~21s, well under the 60s GitHub Actions default. For the immediate PR #55 false positive, a one-time `pre-star-rule` label has been applied; once this lands, the label can be removed.
hoainho
added
change-type:bug-fix
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes a false-positive in the Star Check workflow that blocked PR #55 from merging despite the contributor (@AsifpMulla123) correctly starring the repo.
Why
The original workflow had two compounding problems:
checkRepoIsStarredByAuthenticatedUserAtUsernameis not a real Octokit method. Thetryblock always threw → fell through to the fallback.GET /users/{username}/starred/{owner}/{repo}is served from a read-replica that can lag 5–30s behind the primary write. A fresh star therefore returns 404 ~30% of the time on first-time fork PRs.Net effect: contributors who follow the policy (star, then push) get blocked. The maintainer (me) has to manually apply
pre-star-ruleto unblock, which is the same label that's supposed to mean "grandfathered before policy" — semantic drift.What this changes
GET /users/{username}/starred/{owner}/{repo}path directly.lastStatus,lastErr) appended to the failure log so the maintainer can distinguish read-replica lag from real misses.Performance / risk
Verification
pre-star-rulelabel applied; once this merges, I can remove that label and re-trigger the workflow to validate the fix.Cross-references
pre-star-rulelabel be renamed to something likestar-check-bypassto avoid the semantic drift? Open to feedback.